poor
schema design is a separate issue.)
Are there any downsides to changing the order of pg_dump output with
respect to constraints? (Versus requiring users to alter their schema
design.)
--
Mark Shewmaker
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
rows.
A plain "select 1 from tab" returns zero rows when tab is empty.
--
Mark Shewmaker
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
2 NULL
(1 row affected)
1> select 2 as id, max(myfield) from mytable having 2=1
2> go
id
--- --
(0 rows affected)
--
Mark Shewmaker
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3:
On Wed, 2003-12-17 at 19:57, Tom Lane wrote:
> Mark Shewmaker <[EMAIL PROTECTED]> writes:
> > If a "FOR UPDATE executes before LIMIT" rule stopped the function
> > from ever locking a row, it's still curious why didn't it stop the
> >
On Wed, 2003-12-17 at 14:02, Tom Lane wrote:
> Mark Shewmaker <[EMAIL PROTECTED]> writes:
> > In other words: Is this a bug or a user misunderstanding:
>
> You've got the function doing
>
> > LOOP
> > select * into myrow from mytable limit 1
ly test for problems like this.)
3. If there's some really elegant solution out there, such as a
way to do a "select for update where not locked" to search for
rows no one has a conflicting lock on. (To me this would seem
to be the best of all possible solutio
