On Fri, 11 Mar 2005 01:14:31 -0500, Tom Lane wrote:
> Nicolai Tufar <[EMAIL PROTECTED]> writes:
> > Very well, I too, tend to think that importing some else's solution
> > is the way to go. Tom, have you looked at Trio?
>
> I have not seen it ... but if it looks reasonable to you, have a go
> at i
Nicolai Tufar <[EMAIL PROTECTED]> writes:
> Very well, I too, tend to think that importing some else's solution
> is the way to go. Tom, have you looked at Trio?
I have not seen it ... but if it looks reasonable to you, have a go
at it.
regards, tom lane
-
Tom Lane wrote:
> The CVS-tip implementation is fundamentally broken and won't work even
> for our internal uses. I've not wasted time complaining about it
> because I thought we were going to replace it. If we can't find a
> usable replacement then we're going to have to put a lot of effort
> in
[EMAIL PROTECTED] wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > Please see my posting about using a macro for snprintf. If the
> >> current
> >> > implementation of snprintf is enough for our existing translation
> >> users
> >> > we probably don't need to add anything more to it b
[EMAIL PROTECTED] writes:
>>> Please see my posting about using a macro for snprintf.
> Wasn't the issue about odd behavior of the Win32 linker choosing the wrong
> vnsprintf?
You're right, the point about the macro was to avoid linker weirdness on
Windows. We need to do that part in any case.
Hi Evgen,
How's the syncing with HEAD going?
Cheers,
Chris
Evgen Potemkin wrote:
Ok, I'm started porting it to 8.0.1 and will fix this also.
By the way, did you know any test suit for such queries? To make some
regression test.
Regards, Evgen
I tested you patch, and it's good work. I would all me
Greg Stark wrote:
>
> Kevin Brown <[EMAIL PROTECTED]> writes:
>
> > Hence, it makes sense to go ahead and run the query, but issue a
> > warning at the very beginning, e.g. "WARNING: query JOINs tables > of tables> without otherwise referencing or making use of those
> > tables. This may cause
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Please see my posting about using a macro for snprintf. If the
>> current
>> > implementation of snprintf is enough for our existing translation
>> users
>> > we probably don't need to add anything more to it because snprintf
>> will
>> > not be exp
BUT after clustering triples according to an index on att1:
select relname, relpages from pg_class ;
relname | relpages
-+--
triples | 142 (8KB/buffer)
142 * 8 * 1024 = 1,163,264 Bytes
Is there any comp
Laszlo Hornyak wrote:
IMHO this is why decoupling is good and neccesary. If one configures
the RDBMS to use different another of data, then I simply replace a
couple of lines in the data mapping configuration. In the case of
custom datatypes in PostgreSQL, the same happens. This is no code
modi
Tom Lane wrote:
> Bruce Momjian writes:
> > Please see my posting about using a macro for snprintf. If the current
> > implementation of snprintf is enough for our existing translation users
> > we probably don't need to add anything more to it because snprintf will
> > not be exported to client
Bruce Momjian writes:
> Please see my posting about using a macro for snprintf. If the current
> implementation of snprintf is enough for our existing translation users
> we probably don't need to add anything more to it because snprintf will
> not be exported to client applications.
The CVS-tip
Thomas Hallgren wrote:
Laszlo,
I worked on this and created some interface for decoupling java
datatypes
and their representations. In my implementation the mapping is N:N,
so it
is not directly applicable to your schema, but perhaps you can use some
piece of it.
I am not ready with all default d
"Barry Lind" <[EMAIL PROTECTED]> writes:
> On Oracle 9.2 you get 0, 0, 0, and 2 rows.
Really!? Well, we always knew they were a bit standards-challenged ;-).
I have more faith in DB2 being an accurate implementation of the spec.
regards, tom lane
On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
wrote:
> Please see my posting about using a macro for snprintf. If the current
> implementation of snprintf is enough for our existing translation users
> we probably don't need to add anything more to it because snprintf will
> not be expo
Tom Lane wrote:
Would those of you with access to other DBMSes try this:
create table tab (col integer);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
insert into tab values(1);
insert into tab values(2);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
I claim that a SQL-c
On Thu, 10 Mar 2005 20:07:13 +0200 (EET), Ioannis Theoharis
<[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> i have a table:
>
> create table triples(
> att0 varchar(1000),
> att1 int4,
> att2 varchar(20),
> att3 varchar(1000)
> )
>
> My table has 990 raws.
>
> The (possibly w
Would you please check current CVS? I think I addressed most of these
issues already.
---
Nicolai Tufar wrote:
> > On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote:
> >
> > Applied.
>
> Thanks a lot. The patch
Nicolai Tufar wrote:
> On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
> wrote:
> > > What do you think about it? Shall I abandon FreeBSD and go ahead
> > > Incorporating Trio?
> >
> > Yes, maybe just add the proper %$ handling from Trio to what we have
> > now.
>
> Adding proper %$ from
On Thu, 10 Mar 2005 12:44:50 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Would those of you with access to other DBMSes try this:
>
On informix 9.21.UC4
> create table tab (col integer);
> select 1 from tab having 1=0;
>
returns no rows
> select 1 from tab having 1=1;
>
returns no rows
> inser
On Thu, Mar 10, 2005 at 12:44:50PM -0500, Tom Lane wrote:
> Would those of you with access to other DBMSes try this:
DB2/LINUX 8.1.6
> create table tab (col integer);
> select 1 from tab having 1=0;
1
---
0 record(s) selected.
> select 1 from tab having 1=1;
1
-
All,
I visited #postgresql @ FreeNode and asked about how to make pg use pam
about a week ago (specifically I wanted to auth against LDAP). I was
told to figure it out and write a doc...
Here is my attempt at doing so: http://itc.musc.edu/wiki/PostGreSQL
Please review for accuracy and/or proo
On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
wrote:
> > What do you think about it? Shall I abandon FreeBSD and go ahead
> > Incorporating Trio?
>
> Yes, maybe just add the proper %$ handling from Trio to what we have
> now.
Adding proper %$ from Trio will require too much effort. I wo
Tom Lane wrote:
>
> Would those of you with access to other DBMSes try this:
>
> create table tab (col integer);
> select 1 from tab having 1=0;
> select 1 from tab having 1=1;
> insert into tab values(1);
> insert into tab values(2);
> select 1 from tab having 1=0;
> select 1 from tab having 1=1;
On Oracle 9.2 you get 0, 0, 0, and 2 rows.
--Barry
SQL> create table tab (col integer);
Table created.
SQL> select 1 from tab having 1=0;
no rows selected
SQL> select 1 from tab having 1=1;
no rows selected
SQL> insert into tab values (1);
1 row created.
SQL> insert into tab values (2);
Tom Lane wrote:
Would those of you with access to other DBMSes try this:
create table tab (col integer);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
insert into tab values(1);
insert into tab values(2);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
I claim that a SQL-c
Title: RE: [HACKERS] Raw size
>
> 990 * 2072 = 2,051,280 Bytes
>
> BUT after clustering triples according to an index on att1:
>
>
> 142 * 8 * 1024 = 1,163,264 Bytes
>
>
> Is there any compression or what?
>
varchar means 'character varying'. What varies is the length. So a varchar(1
Title: RE: [HACKERS] We are not following the spec for HAVING without GROUP BY
> Would those of you with access to other DBMSes try this:
Results for "Microsoft SQL Server 2000 - 8.00.944 (Intel X86)":
---
(0 row(s) affected)
---
1
(1
Hi,
i have a table:
create table triples(
att0 varchar(1000),
att1 int4,
att2 varchar(20),
att3 varchar(1000)
)
My table has 990 raws.
The (possibly wrong) way, with wich i compute the size of the table is:
att0: 1000 * 1 Byte + 4 = 1004 Bytes
att2: 20 * 1 Byte
I wrote:
> This is quite clear that the output of a HAVING clause is a "grouped
> table" no matter whether the query uses GROUP BY or aggregates or not.
> What that means is that neither the HAVING clause nor the targetlist
> can use any ungrouped columns except within aggregate calls; that is,
>
I wrote:
> "Milen A. Radev" <[EMAIL PROTECTED]> writes:
>> I review the log every morning. In the beginning I got "wraparound
>> failure" warnings every third day. But from a week I got those warnings
>> every day. Well we have one table in one database where there are a lot
>> of inserts, but not
Hello,
I'd like to start working on the following TODO item:
Referential Integrity / Support triggers on columns
Is somebody else already working on this?
Bye :)
Chris.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Laszlo,
I worked on this and created some interface for decoupling java datatypes
and their representations. In my implementation the mapping is N:N, so it
is not directly applicable to your schema, but perhaps you can use some
piece of it.
I am not ready with all default data types, but the most i
Thomas,
I worked on this and created some interface for decoupling java datatypes
and their representations. In my implementation the mapping is N:N, so it
is not directly applicable to your schema, but perhaps you can use some
piece of it.
I am not ready with all default data types, but the most
> What that means is that neither the HAVING clause nor the targetlist
> can use any ungrouped columns except within aggregate calls; that is,
>
> select col from tab having 2>1
Informix:
select tabname from systables having 2 > 1;
294: The column (tabname) must be in the GROUP BY list.
35 matches
Mail list logo
