On 2011-12-17 22:36, Bèrto ëd Sèra wrote:
>>I see. So this has to do with the union; after combining the two
>>queries, the tables from the FROM clauses are no longer available.
>
> this has nothing to do with the UNION, but with the fact that the result
> set is ordered after being produced, so y
On 2011-12-17 10:02, Andreas Kretschmer wrote:
> Stefan Weiss wrote:
>>
>> SELECT name
>> FROM dossier_contact_v
>> WHERE dossier_id = 56993
>>AND ctype = 234
>> UNION
>> SELECT name
>> FROM dossier_con
Assuming the following simple setup with two data tables, one mapping
table, and one view -
--
CREATE TABLE dossier (
id SERIAL NOT NULL PRIMARY KEY
);
CREATE TABLE contact (
id SERIAL NOT NULL PRIMARY K
lower than one
> query on a bigger table, but youu save precious cache space, so in the end
> it could be faster.
Thank you for your insight. We will rename the columns, add the CHECK
and go ahead with this setup.
regards,
stefan weiss
---(end of broadcast)-
ding to the MySQL documentation, "Rudimentary support
for triggers is included beginning with MySQL 5.0.2". The MySQL
compatibility requirement is none of my doing, I have given up trying to
educate my customers about the benefits of a real database...
regards,
stefan weiss
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
ntioned above?
We are also thinking of precalculating possible connection chains, or
trees, at night (to a certain depth) in order to avoid performance
problems in the peak hours. Any ideas on how such precalculated results
could be stored and queried efficiently?
Thanks in advance,
Stefa
On Thursday, 11 November 2004 09:23, Gaetano Mendola wrote:
> Stefan Weiss wrote:
> > These tables are connected by foreign keys, but without "on delete"
> > triggers.
>
> Why "without" ? Are you looking to solve a problem introduced by
> yourself ?
On Wednesday, 10 November 2004 18:28, Tom Lane wrote:
> Achilleus Mantzios <[EMAIL PROTECTED]> writes:
> > Just a very naive thought
> > Wouldn't make more sense to allow nested begin/commit/rollback blocks?
>
> We actually had it working that way initially, but changed to the
> spec-defined be
Re,
thanks for all the replies.
On Tuesday, 29 June 2004 00:17, Dmitri Bichko wrote:
> As far as TRUE and FALSE go, from what I know you can use = to compare
> them with boolean columns, unless I misunderstood your question.
Sorry, I must have remembered that incorrectly, or maybe I've been
thin
Hi.
I'm just curious - why is it not possible to use the "=" operator to
compare values with NULL? I suspect that the SQL standard specified
it that way, but I can't see any ambiguity in an expression like "AND
foo.bar = NULL". Is it because NULL does not "equal" any value, and the
expression shou
On Monday, 07 June 2004 09:52, Karel Zak wrote:
> http://www.postgresql.org/docs/7.4/static/functions-formatting.html
>
> Warning: to_char(interval, text) is deprecated and should not be
> used in newly-written code. It will be removed in the next version.
This is news for me. Are there any
pg_catalog.pg_function_is_visible(p.oid)
AND p.proname ~ '^alt_to_iso$'
ORDER BY 2, 3, 1, 4;
**
List of functions
Result data type | Schema |Name| Argument data types
--+++-------
Hi.
I have a (simplified) table layout like this:
+-+ +-+
| sub_a | +--+ | sub_b |
+-+ | main | +-+
| id | +--+ | id |
| main_id |
13 matches
Mail list logo
