In article <[EMAIL PROTECTED]>,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> Tom had posted a question about file compression with copy. I thought
>> about it, and I want to through this out and see if anyone things it is a
>> good idea.
>>
>> Currently, the COPY command o
In article <[EMAIL PROTECTED]>,
Martijn van Oosterhout writes:
> On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
>> > T-SQL has statement-level triggers, and they get used a lot (some big apps
>> > ONLY put code in triggers). Statement-level triggers are very efficient
>> > for
>
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> Harald Fuchs <[EMAIL PROTECTED]> writes:
>> Bruce Momjian writes:
>>> A leap second will show as 24:00:00. It is a valid time.
>> Shouldn't such a leap second be represented
In article <[EMAIL PROTECTED]>,
Bruce Momjian writes:
> Tony Caduto wrote:
>> Hi,
>> I just noticed today that Postgresql accepts a value of 24:00:00, this
>> is for sure not correct as there is no such thing as 24:00:00
>>
>> PG Admin III will display this value just fine which is also incorre
In article <[EMAIL PROTECTED]>,
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
mysql> SELECT EXTRACT(MICROSECOND FROM '2003-01-02 10:30:01.00123');
>> +---+
>> | EXTRACT(MICROSECOND FROM '2003-01-02 10:30:01.00123') |
>> +---
In article <[EMAIL PROTECTED]>,
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Sun, Nov 27, 2005 at 07:44:55PM +, Simon Riggs wrote:
>> not have any unique indexes or row triggers. It should be possible to
>> take advantage of this automatically when those requirements are met,
>> without any
In article <[EMAIL PROTECTED]>,
Martijn van Oosterhout writes:
> It's even sillier than that:
> test=# SELECT substring ('1234567890' FOR 4::bigint);
> substring
> ---
> (1 row)
> test=# SELECT substring ('1234567890' FOR 4::int);
> substring
> ---
> 1234
> (1 row)
> Look
Consider the following:
CREATE TEMP TABLE tbl (
id SERIAL NOT NULL,
PRIMARY KEY (id)
);
COPY tbl (id) FROM stdin;
1
2
3
4
\.
SELECT substring ('1234567890' FOR (SELECT count (*) FROM tbl)::int);
This returns '1234', as expected. But
SELECT substring ('1234567890' F
In article <[EMAIL PROTECTED]>,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>
>>> it's great news. My personal opinion about formating NULL values
>>> '{a, NULL, b}' -- longer, clean NULL is NULL
>>>
>>
>> Unfortunately, that alr
In article <[EMAIL PROTECTED]>,
Gregory Maxwell <[EMAIL PROTECTED]> writes:
> On 11/4/05, Martijn van Oosterhout wrote:
>> Yeah, and while one way of removing that dependance is to use ICU, that
>> library wants everything in UTF-16. So we replace "copying to add NULL
>> to string" with "converti
In article <[EMAIL PROTECTED]>,
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> * optional interface which sends a row typeoid along with each row in a
>> result set
> Oh, and 'select rowid, * from table' which returns special rowid
> column that just incrementally numbers each row.
Why?
In article <[EMAIL PROTECTED]>,
Richard Huxton writes:
>> I just don't see why non-interactive mode does need such a switch
>> because there is no way to check if there was an error. So just put
>> two queries there and hope one will work?
> DROP TABLE foo;
> CREATE TABLE foo...
Ah, my pet peev
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> One possible approach is to do the invalidation on a sufficiently coarse
> grain that we don't care. For example, I would be inclined to make any
> change in a table's schema invalidate all plans that use that table at
> all;
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> One possible approach is to do the invalidation on a sufficiently coarse
> grain that we don't care. For example, I would be inclined to make any
> change in a table's schema invalidate all plans that use that table at
> all;
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> David Wheeler <[EMAIL PROTECTED]> writes:
>> On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
>>> I think we should favor libpq usage wherever possible and only
>>> re-implement it in the native language when required, like f
In article <[EMAIL PROTECTED]>,
Oliver Jowett <[EMAIL PROTECTED]> writes:
> I think you just made my point for me. C++ allows default parameters
> and resolves the ambiguity by disallowing ambiguous calls when they
> happen.
> I'm not sure why C++ doesn't disallow it at declaration time off the
In article <[EMAIL PROTECTED]>,
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Right, the reason it's important is that there are some things now that
> are potentially tied together. If you have table A with rows A1,...,An and
> table B with rows B1,...,Bm and the delete join condition gives the two
In article <[EMAIL PROTECTED]>,
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> In exactly the same order as for single-table DELETEs -
>> implementation-defined.
> I think you probably meant in an unspecified order.
> Implementation-defined really doesn't mean anything when you're trying to
> defin
In article <[EMAIL PROTECTED]>,
Josh Berkus <[EMAIL PROTECTED]> writes:
> Harald,
>> You're talking about "the deletion target table". Sorry to mention
>> the M word again, but MySQL allows deleting from more than one table
>> at the same time. Should we support that?
> Nope. In fact, I'd arg
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>> What about
>> DELETE FROM staff JOIN users ...
>> then?
> I don't much care for that, mainly because in my mind "x JOIN y" should
> always be semantically equivalent to "y JOIN x". I t
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> Well, as yall have pointed out, the feature is not sql spec (for some
>> reason I thought it had been put in) so since the update syntax seems
>> quite similar to oracles, perhaps the
In article <[EMAIL PROTECTED]>,
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Mon, 2004-07-19 at 12:36, Josh Berkus wrote:
>> Rod,
>>
>> > I think what we want is a clean template without all of the extras that
>> > template1 has.
>>
>> We have this, it's called Template0.
> Doesn't work for me.
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
>> I was toying around with idea of converting all the memory related
>> parameters in postgresql.conf to kilobytes for simplicity and
>> uniformity.
> Why is that a good idea?
In article <[EMAIL PROTECTED]>,
Chris Campbell <[EMAIL PROTECTED]> writes:
> Harald Fuchs wrote:
>> Why don't you just do
>> ( echo "-- This is my comment"
>> pg_dump whatever
>> ) > dumpfile
>> ?
> How could I dump using the c
24 matches
Mail list logo
