Dmitriy Igrishin writes:
> 2013/4/5 Tom Lane
>> We do not generally forbid ALTER on extension members. During
>> development for instance a quick ALTER can be a whole lot more
>> convenient than dropping and reloading the whole extension.
> Debatable, because in practice during development it's
2013/4/5 Tom Lane
> Dmitriy Igrishin writes:
> > According to
> > http://www.postgresql.org/docs/9.2/static/extend-extensions.html
> > "PostgreSQL will not let you drop an individual object contained in an
> > extension, except by dropping the whole extension."
> > But this rule does not apply t
Dmitriy Igrishin writes:
> According to
> http://www.postgresql.org/docs/9.2/static/extend-extensions.html
> "PostgreSQL will not let you drop an individual object contained in an
> extension, except by dropping the whole extension."
> But this rule does not apply to domain constraints, i.e. it is
Hey hackers,
According to
http://www.postgresql.org/docs/9.2/static/extend-extensions.html
"PostgreSQL will not let you drop an individual object contained in an
extension, except by dropping the whole extension."
But this rule does not apply to domain constraints, i.e. it is not possible
to drop
On Friday 09 December 2005 09:22, Jan Wieck wrote:
> On 12/8/2005 9:12 PM, Luca Pireddu wrote:
> > I wrote a trigger function with the intent of preventing the deletion of
> > a parent record when a referencing record would not allow it. However,
> > the result is that the referencing record stays
On 12/8/2005 9:12 PM, Luca Pireddu wrote:
I wrote a trigger function with the intent of preventing the deletion of a
parent record when a referencing record would not allow it. However, the
result is that the referencing record stays, but the referenced one is gone,
so that my foreign key con
Luca Pireddu <[EMAIL PROTECTED]> writes:
> I wrote a trigger function with the intent of preventing the deletion of a
> parent record when a referencing record would not allow it. However, the
> result is that the referencing record stays, but the referenced one is gone,
> so that my foreign ke
I wrote a trigger function with the intent of preventing the deletion of a
parent record when a referencing record would not allow it. However, the
result is that the referencing record stays, but the referenced one is gone,
so that my foreign key constraint is not respected. The behaviour can
Keary Suska <[EMAIL PROTECTED]> writes:
> on 9/5/05 6:51 PM, [EMAIL PROTECTED] purportedly said:
>> In any case, AFAICS this would only be an issue if you do
>> "su postgres -c postmaster" rather than "su -l postgres -c postmaster"
>> and the former is to be avoided for many reasons besides this on
on 9/5/05 6:51 PM, [EMAIL PROTECTED] purportedly said:
>> FYI, it appears that you cannot start the postmaster when your current
>> working directory is not accessible by the postgres user:
>
> Is there a good reason that this case should work? I don't think it's
> very easy to fix given that we
Keary Suska <[EMAIL PROTECTED]> writes:
> FYI, it appears that you cannot start the postmaster when your current
> working directory is not accessible by the postgres user:
Is there a good reason that this case should work? I don't think it's
very easy to fix given that we have to resolve the act
FYI, it appears that you cannot start the postmaster when your current
working directory is not accessible by the postgres user:
shell-init: could not get current directory: getcwd: cannot access parent
directories: Permission denied
LOG: 0: could not identify current directory: Permission de
Martijn,
I realize that the change I'm proposing might be too complex to be added
in the upcoming 8.0 release. I do find this discussion interesting
though, so please bear with me while I try to tie up some loose ends.
UPDATE [ ONLY ] table SET col = expression [, ...]
[ FROM fromlist ]
[
Martijn van Oosterhout wrote:
Sure, that's what you could do, but it makes the query rather more
complex than it needs to be.
Do you consider this overly complex? Compare:
DELETE FROM x WHERE EXISTS (SELECT * FROM table WHERE x.a = table.a and
x.b > table.b and table.c = 4)
to:
DELETE FROM x,
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Wed, Oct 27, 2004 at 22:10:05 +0200,
>> 2. Let's change so that "add_missing_from" is disabled by default and
>> doesn't affect the DELETE statement at all.
> That is supposed to happen. My memory was that 8.0 was the release that
> the default was
On Wed, Oct 27, 2004 at 22:10:05 +0200,
> 2. Let's change so that "add_missing_from" is disabled by default and
> doesn't affect the DELETE statement at all.
That is supposed to happen. My memory was that 8.0 was the release that
the default was going to change, but if not then it should be 8.1.
Martijn,
I realize that the change I'm proposing might be too complex to be added
in the upcoming 8.0 release. I do find this discussion interesting
though, so please bear with me while I try to tie up some loose ends.
UPDATE [ ONLY ] table SET col = expression [, ...]
[ FROM fromlist ]
[ WHE
I didn't see that join syntax in the documentation for delete, thanks
for pointing it out.
MS SQL Server syntax for a delete is a little less confusing, IMHO.
instead of DELETE FROM x WHERE x.a = table.a and x.b > table.b and table.c = 4;
they have DELETE x FROM x join table on x.a = table.a and
On Wed, Oct 27, 2004 at 12:15:10AM +0200, Thomas Hallgren wrote:
> Martijn,
> > Do you have a better
> >suggestion, other than forbidding the currently allowed syntax?
> >
> Yes I do.
>
> We agree that my second example should be disallowed since the semantics
> of the FROM clause is different fo
Martijn,
> Do you have a better
suggestion, other than forbidding the currently allowed syntax?
Yes I do.
We agree that my second example should be disallowed since the semantics
of the FROM clause is different for a DELETE so the "add_missing_from"
is actually not adding to a FROM clause, it is
On Tue, Oct 26, 2004 at 06:21:23PM +0200, Thomas Hallgren wrote:
> Do you consider this overly complex? Compare:
>
> DELETE FROM x WHERE EXISTS (SELECT * FROM table WHERE x.a = table.a and
> x.b > table.b and table.c = 4)
>
> to:
>
> DELETE FROM x, table WHERE x.a = table.a and x.b > table.b an
On Tue, Oct 26, 2004 at 05:25:57PM +0200, Thomas Hallgren wrote:
> If the WHERE clause that defines the criteria for deletion involves more
> than one table, then you'd use a sub select and that has a FROM clause
> of its own.
Sure, that's what you could do, but it makes the query rather more
co
Stephan,
Perhaps the 8.0 would be a perfect time since it's a change of the major
number.
Maybe, but I think it'll be a hard sell without a replacement for the
delete form that works when it's off.
I'm not sure I understand this. Apparently you want tables to be added
to the FROM clause of
On Mon, 25 Oct 2004, Thomas Hallgren wrote:
> Stephan,
>
> > In general, when we add a backwards compatibility option, we give
> > a couple of versions before the default is changed.
> >
> Perhaps the 8.0 would be a perfect time since it's a change of the major
> number.
Maybe, but I think it'
Thomas Hallgren wrote:
Steven,
> That assumes that developers will implement queries in their code
> without testing them. Unfortunately, that's probably not too far from
> reality. I've thought of it as a nice "debugging" feature while I'm
> trying to hammer out a complicated query for the fir
Stephan,
> In general, when we add a backwards compatibility option, we give
> a couple of versions before the default is changed.
>
Perhaps the 8.0 would be a perfect time since it's a change of the major
number.
> In addition, until we have a form of delete which allows a "from"
> list, there a
* Thomas Hallgren <[EMAIL PROTECTED]> [2004-10-25 19:06:40 +0200]:
> I don't see how that makes a difference really.
/me notes the timestamp on his post and vows never to post before 8am
again.
--
Steven Klassen - Lead Programmer
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL R
Steven,
> That assumes that developers will implement queries in their code
> without testing them. Unfortunately, that's probably not too far from
> reality. I've thought of it as a nice "debugging" feature while I'm
> trying to hammer out a complicated query for the first time.
I don't see how th
On Mon, 25 Oct 2004, Thomas Hallgren wrote:
> Stephan Szabo wrote:
>
> > It's enabled in large part for backwards compatibility. There's a
> runtime
> > option that controls the behavior (add_missing_from).
> >
> IMHO, it would be a more natural choice to have the add_missing_from
> disabled b
* Thomas Hallgren <[EMAIL PROTECTED]> [2004-10-25 15:52:20 +0200]:
> IMHO, it would be a more natural choice to have the add_missing_from
> disabled by default. Why would anyone *ever* want faulty SQL being
> magically "patched up" by the dbms?
That assumes that developers will implement queries
Stephan Szabo wrote:
> It's enabled in large part for backwards compatibility. There's a
runtime
> option that controls the behavior (add_missing_from).
>
IMHO, it would be a more natural choice to have the add_missing_from
disabled by default. Why would anyone *ever* want faulty SQL being
magi
On Sat, 2004-10-23 at 07:35, Philip Hofstetter wrote:
> It would just have been easier to find if PostgreSQL actually had
> told me so (I'm not getting those NOTICEs from PHP...).
As far as I can tell, Apache or PHP snarfs up all the messages that
postgres generates before they can get to the po
On Sat, 23 Oct 2004, Philip Hofstetter wrote:
> > As for what's SQL standard, I think by a strict definition your query
> > shouldn't be allowed at all, referencing an undefined table.
>
> This is exactly what I think too. I mean: I know I made an error in my
> query. It would just have been easie
On Sat, Oct 23, 2004 at 02:35:20PM +, Philip Hofstetter wrote:
> >As for what's SQL standard, I think by a strict definition your query
> >shouldn't be allowed at all, referencing an undefined table.
>
> This is exactly what I think too. I mean: I know I made an error in my
> query. It would
Hi,
Martijn van Oosterhout wrote:
popscan_light=> select aliasa.name, aliasb.name2 from a aliasa left join
b aliasb using (id) order by b.name2;
NOTICE: adding missing FROM-clause entry for table "b"
name | name2
---+---
gnegg | gnegglink
blepp | blepplink
gnegg | gnegglink
blepp |
On Sat, Oct 23, 2004 at 02:17:16PM +, Philip Hofstetter wrote:
> Hello,
>
> I think, I found a bug, but maybe it's just my stupidity. Granted: What
> I did was an error on my part, but I still think, PostgreSQL should not
> do what it does.
... snip ...
> popscan_light=> select aliasa.name
Hello,
I think, I found a bug, but maybe it's just my stupidity. Granted: What
I did was an error on my part, but I still think, PostgreSQL should not
do what it does.
I've already created a simple testcase:
popscan_light=> create table a (id serial, name varchar(10), primary
key(id)) without o
On Wed, 28 Apr 2004 12:33:15 +0300, "Bogdan Vatkov"
<[EMAIL PROTECTED]> wrote:
>SQL error:
>ERROR: JOIN/ON clause refers to "vras_audio_records", which is not part of JOIN
In
SELECT ... FROM a, b LEFT JOIN c ON (a.id = ...)
the LEFT JOIN operator has higher precedence than the comma, so
Hello Richard,
Once, Thursday, January 20, 2000, 3:04:43 PM, you wrote:
RH> - Original Message -
RH> From: Yury Don <[EMAIL PROTECTED]>
RH> To: pgsql-general <[EMAIL PROTECTED]>
RH> Sent: Wednesday, January 19, 2000 11:32 AM
RH> Subject: Re[2]: [GENERAL] Bug o
- Original Message -
From: Yury Don <[EMAIL PROTECTED]>
To: pgsql-general <[EMAIL PROTECTED]>
Sent: Wednesday, January 19, 2000 11:32 AM
Subject: Re[2]: [GENERAL] Bug or my crooked hands?
> >> I have the following situation:
> >>
> >> CREATE T
Hello J.,
Once, Wednesday, January 19, 2000, 4:19:12 PM, you wrote:
>> Hello All,
>>
>> I have the following situation:
>>
>> CREATE TABLE "Contacts" (
>> "Contact" Serial,
>> "StuffTheir" Text,
>> "TheDate" datetime DEFAULT TEXT 'now',
>> "Subj" Text,
> Hello All,
>
> I have the following situation:
>
> CREATE TABLE "Contacts" (
> "Contact" Serial,
> "StuffTheir" Text,
> "TheDate" datetime DEFAULT TEXT 'now',
> "Subj" Text,
> "CustomerId" int4,
> "Agent" int4,
> "ActionType"
Hello All,
I have the following situation:
CREATE TABLE "Contacts" (
"Contact" Serial,
"StuffTheir" Text,
"TheDate" datetime DEFAULT TEXT 'now',
"Subj" Text,
"CustomerId" int4,
"Agent" int4,
"ActionType" int2,
"Done"
43 matches
Mail list logo
