On Fri, Sep 11, 2009 at 6:56 PM, Emmanuel Cecchet wrote:
> Robert Haas wrote:
>>
>> http://developer.postgresql.org/pgdocs/postgres/sql-explain.html
>>
>
> Just out of curiosity, it looks like I could write something like:
> EXPLAIN (ANALYZE TRUE, COSTS FALSE, VERBOSE TRUE, COSTS TRUE) statement
>
On 9/11/09 3:56 PM, Emmanuel Cecchet wrote:
> Robert Haas wrote:
>> http://developer.postgresql.org/pgdocs/postgres/sql-explain.html
>>
> Just out of curiosity, it looks like I could write something like:
> EXPLAIN (ANALYZE TRUE, COSTS FALSE, VERBOSE TRUE, COSTS TRUE) statement
>
> What is the
On Fri, Sep 11, 2009 at 12:41:21PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
>
> > what you you want is full type-inference as it's only that which
> > will allow you to track back up the layers and assign consistent
> > types to arbitrary expressions like the above.
>
> Well, obviously
Robert Haas wrote:
http://developer.postgresql.org/pgdocs/postgres/sql-explain.html
Just out of curiosity, it looks like I could write something like:
EXPLAIN (ANALYZE TRUE, COSTS FALSE, VERBOSE TRUE, COSTS TRUE) statement
What is the expected behavior if someone puts multiple time the same
On Fri, Sep 11, 2009 at 01:37:00PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Yeah, I am. When you have queries built based on which fields on a
> > QBE window are filled by a user, it's not hard to come up with a
> > clause like:
>
> > AND (somedate < COALESCE(NULL, NULL) OR ...)
>
* Robert Haas (robertmh...@gmail.com) wrote:
> Integrating hstore into core and then
> making COPY able to execute a subquery to get its options is certainly
> not easier than a straightforward grammar modification; it's taking a
> small project and turning it into several big ones.
To be honest,
Greg Smith wrote:
The full set of new behavior here I'd like to see allows adjusting:
-Accept or reject rows with extra columns?
-Accept or reject rows that are missing columns at the end?
--Fill them with the default for the column (if available) or NULL?
-Save rejected rows?
--To a single syst
On Fri, 2009-09-11 at 17:35 -0400, Tom Lane wrote:
> Eh? It's a null value of a composite type. The above is a type
> violation.
The spec calls it "the null value" which is included in all domains
(Framework 4.4.2). However, in the same section, it mentions "the data
type of the null value", so
Josh Berkus wrote:
Greg,
The performance of every path to get data into the database besides COPY
is too miserable for us to use anything else, and the current
inflexibility makes it useless for anything but the cleanest input data.
One potential issue we're facing down this road is
Tom Lane wrote:
> I'm expecting coerce_type to fail, along the lines of
> ERROR: failed to find conversion function from unknown to whatever
OK. After playing with that and reading the code in more depth, I now
see what you've been saying.
[picks up lance and takes aim at windmill]
It still
Greg,
> The performance of every path to get data into the database besides COPY
> is too miserable for us to use anything else, and the current
> inflexibility makes it useless for anything but the cleanest input data.
One potential issue we're facing down this road is that current COPY has
a du
Robert Haas writes:
> On Fri, Sep 11, 2009 at 5:32 PM, Tom Lane wrote:
>> Why? We'd certainly still support the old syntax for existing options,
>> just as we did with EXPLAIN.
> None of the syntax proposals upthread had that property, which doesn't
> mean we can't do it. However, we'd need so
On Fri, Sep 11, 2009 at 5:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> The biggest problem I have with this change is that it's going to
>> massively break anyone who is using the existing COPY syntax.
>
> Why? We'd certainly still support the old syntax for existing options,
> just as we did
Jeff Davis writes:
> To make that interpretation work I think you would need to say that
> ROW(NULL,NULL) _is_ the null value,
Right...
> and you would have to allow things like:
> select 1 + row(null,null);
Eh? It's a null value of a composite type. The above is a type
violation.
Robert Haas writes:
> The biggest problem I have with this change is that it's going to
> massively break anyone who is using the existing COPY syntax.
Why? We'd certainly still support the old syntax for existing options,
just as we did with EXPLAIN.
regards, tom lane
On Fri, 11 Sep 2009, Tom Lane wrote:
If you believe that somebody might think of a new per-column COPY
behavior in the future, then the same issue is going to come up again.
While Andrew may have given up on a quick hack to work around his recent
request, I don't have that luxury. We've alre
2009/9/11 Stephen Frost :
Postgres has a hstore data type which seems well suited for passing
key/value option pairs...
>>
>> Quite apart from any other reason, it is not builtin, so there is no way
>> that any builtin thing can use it.
>
> Clearly, that's fixable.. I think it's a
On Fri, 2009-09-11 at 12:59 -0400, Tom Lane wrote:
> If so then ROW(NULL,NULL) would be
> indistinguishable from NULL and the semantic gripes seem to largely
> go away. It would be a problem for anyone who actually wanted to
> distinguish those two cases, but how much do we care?
Does that violat
On Sep 11, 2009, at 2:35 PM, David E. Wheeler wrote:
On Sep 11, 2009, at 12:42 PM, Tom Lane wrote:
Well, 10.6.1 is out and it's still got the readdir() bug :-(.
Has someone filed a bug report about this with Apple?
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa
Look at th
On Sep 11, 2009, at 2:35 PM, David E. Wheeler wrote:
On Sep 11, 2009, at 12:42 PM, Tom Lane wrote:
Well, 10.6.1 is out and it's still got the readdir() bug :-(.
Has someone filed a bug report about this with Apple?
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa
If no one
On Fri, Sep 11, 2009 at 4:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> Another approach would be to generalize what is allowable as an
>> optional parameter to include a parenthesized column list, but I don't
>> really think that has a lot to recommend it.
>
> Well, maybe it's worth doing. If
* Andrew Dunstan (and...@dunslane.net) wrote:
> Robert Haas wrote:
>>>Postgres has a hstore data type which seems well suited for passing
>>> key/value option pairs...
>
> Quite apart from any other reason, it is not builtin, so there is no way
> that any builtin thing can use it.
Clearl
On Sep 11, 2009, at 12:42 PM, Tom Lane wrote:
Well, 10.6.1 is out and it's still got the readdir() bug :-(.
Has someone filed a bug report about this with Apple?
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Robert Haas writes:
> Another approach would be to generalize what is allowable as an
> optional parameter to include a parenthesized column list, but I don't
> really think that has a lot to recommend it.
Well, maybe it's worth doing. If you believe that somebody might think
of a new per-column
On Fri, Sep 11, 2009 at 12:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 11, 2009 at 11:37 AM, Tom Lane wrote:
>>> No, it *isn't* cheap. Particularly not for COPY, for which we need an
>>> ad-hoc parser in psql.
>
>> :-( That's definitely a complication, although it seems to me i
I wrote:
> Jan Otto writes:
>> The bug in readdir() appeared in the final snow leopard too. Anybody
>> with Snow Leopard installed can check this, with simply doing the
>> regression tests (make check). The tablespace regression test is
>> failing.
>> The patch i sent in works around the issue. i
Magnus Hagander writes:
> On Fri, Sep 11, 2009 at 10:44, Heikki Linnakangas
>> Here's a patch implementing that, and changing pgrename() to check for
>> ERROR_SHARING_VIOLATION and ERROR_LOCK_VIOLATION like pgwin32_open()
>> does, instead of ERROR_ACCESS_DENIED.
> I have definitely seen AV progra
Emmanuel Cecchet writes:
> Tom Lane wrote:
>> The important point is to look at the grammar, which doesn't have any
>> idea what the specific options are in the list.
> I understand the convenience from a developer perspective but I wonder
> how this improves the user experience.
It's all in th
On Fri, Sep 11, 2009 at 10:44, Heikki Linnakangas
wrote:
> (moving to pgsql-hackers)
>
> Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> A completely different approach would be to treat any failure on all
>>> platforms as non-fatal. We shouldn't really cut the checkpoint short if
>>> recycling
Tom Lane wrote:
Robert Haas writes:
Or look at your CVS/git checkout.
The important point is to look at the grammar, which doesn't have any
idea what the specific options are in the list. (Well, okay, it had
to have special cases for ANALYZE and VERBOSE because those are reserved
wor
"Kevin Grittner" writes:
> Tom Lane wrote:
>> It's what happens afterwards that's the problem --- try it and see.
> Anything in particular I should test or be looking for, or will the
> error of my ways be glaringly obvious on any usage?
I'm expecting coerce_type to fail, along the lines of
ER
Tom Lane wrote:
> "Kevin Grittner" writes:
>> I was thinking of changing what is currently done, for example,
>> here:
>
>> newc->coalescetype = select_common_type(pstate, newargs,
>> "COALESCE", NULL);
>
>> Is that so late as you say, or is there a reason that can't work?
>
> It's what happ
David Fetter writes:
> On Fri, Sep 11, 2009 at 11:37:33AM -0400, Tom Lane wrote:
>> No, it *isn't* cheap. Particularly not for COPY, for which we need
>> an ad-hoc parser in psql.
> Is there some way we can use the regular parser, as plpgsql is moving
> to, or is there just too much wound into t
On Fri, Sep 11, 2009 at 11:37:33AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > While I'm at least as big a fan of generic options as the next
> > person, syntax is cheap.
>
> No, it *isn't* cheap. Particularly not for COPY, for which we need
> an ad-hoc parser in psql.
Is there some way we
Sam Mason wrote:
> what you you want is full type-inference as it's only that which
> will allow you to track back up the layers and assign consistent
> types to arbitrary expressions like the above.
Well, obviously that would fix it; I'm not clear on why *only* that
would fix it. It seemed t
"Greg Sabino Mullane" writes:
>> We also very occasionally step in and make a decision if -hackers (or
>> another group) is deadlocked over an issue. For example, the whole
>> 'change the name' debate.
> I wouldn't really hold that up as a shining example of a core decision. :)
The point of c
"Kevin Grittner" writes:
> I was thinking of changing what is currently done, for example, here:
> newc->coalescetype = select_common_type(pstate, newargs, "COALESCE",
> NULL);
> Is that so late as you say, or is there a reason that can't work?
It's what happens afterwards that's the problem
2009/9/11 Tom Lane :
> Merlin Moncure writes:
>> If you are going to use printf format codes, which is good and useful
>> being something of a standard, I'd call routine printf (not format)
>> and actually wrap vsnprintf. The format codes in printf have a very
>> specific meaning: converting nati
On Fri, Sep 11, 2009 at 12:26:45PM -0500, Kevin Grittner wrote:
> Tom Lane wrote:
> > if that weren't true then we wouldn't be arguing about whether
> > COALESCE is wrong.
>
> Yeah, I am. When you have queries built based on which fields on a
> QBE window are filled by a user, it's not hard to
On Fri, Sep 11, 2009 at 06:24:22PM +0100, Sam Mason wrote:
> One thing I've just realized these discussions have pointed out is
> that PG isn't doing the correct thing all the time with types. When
> is it ever valid to see an "unknown" after type checking? AFAICT, it
> shouldn't ever appear and
Tom Lane wrote:
> "Kevin Grittner" writes:
>> I'm only proposing parse-time changes for conditional
>> expressions -- the CASE predicate and its abbreviations.
>
> No, you are not; you are proposing run-time changes, specifically
> the need to coerce unknown to something else long after the poin
On Fri, Sep 11, 2009 at 12:59:04PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > I'm only proposing parse-time changes for conditional
> > expressions -- the CASE predicate and its abbreviations.
>
> No, you are not; you are proposing run-time changes, specifically the
> need to coerce un
On Fri, Sep 11, 2009 at 12:11 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> If you are going to use printf format codes, which is good and useful
>> being something of a standard, I'd call routine printf (not format)
>> and actually wrap vsnprintf. The format codes in printf have a very
>> spe
"Kevin Grittner" writes:
> I'm only proposing parse-time changes for conditional
> expressions -- the CASE predicate and its abbreviations.
No, you are not; you are proposing run-time changes, specifically the
need to coerce unknown to something else long after the point where
the unknown is just
Sam Mason wrote:
> On Wed, Sep 09, 2009 at 10:25:34AM -0400, Tom Lane wrote:
>> Now admittedly there's probably not any major technical obstacle to
>> making a runtime conversion happen --- it's merely delayed
>> invocation of the destination type's input function. But I find it
>> really ugly f
Robert Haas writes:
> On Fri, Sep 11, 2009 at 11:37 AM, Tom Lane wrote:
>> No, it *isn't* cheap. Particularly not for COPY, for which we need an
>> ad-hoc parser in psql.
> :-( That's definitely a complication, although it seems to me it will
> need substantial work no matter what option we de
Merlin Moncure writes:
> If you are going to use printf format codes, which is good and useful
> being something of a standard, I'd call routine printf (not format)
> and actually wrap vsnprintf. The format codes in printf have a very
> specific meaning: converting native C types to arrays of cha
On Fri, Sep 11, 2009 at 11:37 AM, Tom Lane wrote:
> Robert Haas writes:
>> While I'm at least as big a fan of generic options as the next person,
>> syntax is cheap.
>
> No, it *isn't* cheap. Particularly not for COPY, for which we need an
> ad-hoc parser in psql.
:-( That's definitely a compl
On Fri, Sep 11, 2009 at 10:38 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Is this really all that hard? I'm thinking it could be implemented by
>> using the real C sprintf underneath, passing one % specifier and its
>> corresponding parameter at a time, coerced to whatever the conversion
>>
Robert Haas wrote:
Postgres has a hstore data type which seems well suited for passing
key/value option pairs...
Quite apart from any other reason, it is not builtin, so there is no way
that any builtin thing can use it.
cheers
andrew
--
Sent via pgsql-hackers mail
On Fri, Sep 11, 2009 at 11:19 AM, Robert Haas wrote:
> On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> I think the main benefit of a sprintf type function for PostgreSQL is
>>> in the formatting (setting length, scale, alignment), not in making
>>> concatenation
Robert Haas writes:
> While I'm at least as big a fan of generic options as the next person,
> syntax is cheap.
No, it *isn't* cheap. Particularly not for COPY, for which we need an
ad-hoc parser in psql.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
Tom Lane wrote:
Robert Haas writes:
I don't see any reasonable way to sandwhich the FORCE NOT NULL syntax
into a keyword/value notation.
Any number of ways, for example "force_not_null = true" or multiple
occurrences of "force_not_null = column_name". Andrew was on the verge
of adm
Andrew Dunstan writes:
> Well, I think the objection was that it would slow COPY down to have to
> go though the executor in the copy-as-source scenario. But maybe that
> would happen anyway, and maybe we don't care, we'd just accept that it
> wouldn't be nearly as fast as a raw copy.
I haven'
2009/9/11 Pierre Frédéric Caillaud :
>> I was thinking something like:
>>
>> COPY tablename [ ( column [, ...] ) ] FROM { 'filename' | STDIN }
>> [WITH] [option [, ...]]
>>
>> Where:
>>
>> option := ColId [Sconst] | FORCE NOT NULL (column [,...])
>>
>> I don't see any reasonable way to sandwhich th
On Fri, Sep 11, 2009 at 11:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> I don't see any reasonable way to sandwhich the FORCE NOT NULL syntax
>> into a keyword/value notation.
>
> Any number of ways, for example "force_not_null = true" or multiple
> occurrences of "force_not_null = column_name
I was thinking something like:
COPY tablename [ ( column [, ...] ) ] FROM { 'filename' | STDIN }
[WITH] [option [, ...]]
Where:
option := ColId [Sconst] | FORCE NOT NULL (column [,...])
I don't see any reasonable way to sandwhich the FORCE NOT NULL syntax
into a keyword/value notation.
Post
Robert Haas writes:
> I like the idea of making concatenation more pretty, quite frankly.
> No one has really responded to Pavel's contention that this is what
> to_char() is for.
[ shrug... ] I regard this as a prettier replacement for to_char.
That thing has got nothing whatsoever to recommend
Tom Lane wrote:
Andrew Dunstan writes:
I wrote:
I'd love to be able to do something like
INSERT into foo (x,y,z) select t[3],[t2],[t57] from (COPY RETURNING
t FROM stdin CSV);
Some IRC discussion suggested ways we could do better than that syntax.
I think my current pre
Robert Haas writes:
> I don't see any reasonable way to sandwhich the FORCE NOT NULL syntax
> into a keyword/value notation.
Any number of ways, for example "force_not_null = true" or multiple
occurrences of "force_not_null = column_name". Andrew was on the verge
of admitting we don't need that
On Fri, Sep 11, 2009 at 10:30 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> I think the main benefit of a sprintf type function for PostgreSQL is
>> in the formatting (setting length, scale, alignment), not in making
>> concatenation more pretty.
>
> Exactly, which is why I'm so distressed th
Andrew Dunstan writes:
> I wrote:
>> I'd love to be able to do something like
>>
>> INSERT into foo (x,y,z) select t[3],[t2],[t57] from (COPY RETURNING
>> t FROM stdin CSV);
> Some IRC discussion suggested ways we could do better than that syntax.
> I think my current preferred candidate is som
Robert Haas writes:
> Or look at your CVS/git checkout.
The important point is to look at the grammar, which doesn't have any
idea what the specific options are in the list. (Well, okay, it had
to have special cases for ANALYZE and VERBOSE because those are reserved
words :-(. But future additi
On Fri, Sep 11, 2009 at 10:18 AM, Tom Lane wrote:
> Emmanuel Cecchet writes:
>> The new syntax could look like:
>
>> COPY /tablename/ [ ( /column/ [, ...] ) ]
>> FROM { '/filename/' | STDIN }
>> [ [, BINARY ]
>> [, OIDS ]
>> [, DELIMITER [ AS ] '/delimiter/' ]
>> [, NULL
On Fri, Sep 11, 2009 at 10:53 AM, Emmanuel Cecchet wrote:
> Tom,
>
> I looked at EXPLAIN
> (http://www.postgresql.org/docs/current/interactive/sql-explain.html) and
> there is not a single line of what you are talking about.
> And the current syntax is just EXPLAIN [ ANALYZE ] [ VERBOSE ] /stateme
I wrote:
I'd love to be able to do something like
INSERT into foo (x,y,z) select t[3],[t2],[t57] from (COPY RETURNING
t FROM stdin CSV);
Some IRC discussion suggested ways we could do better than that syntax.
I think my current preferred candidate is something like
COPY foo (a,b
Tom,
I looked at EXPLAIN
(http://www.postgresql.org/docs/current/interactive/sql-explain.html)
and there is not a single line of what you are talking about.
And the current syntax is just EXPLAIN [ ANALYZE ] [ VERBOSE ] /statement
/
If I try to decrypt what you said, you are looking at somethi
Heikki Linnakangas writes:
> Here's a patch implementing that, and changing pgrename() to check for
> ERROR_SHARING_VIOLATION and ERROR_LOCK_VIOLATION like pgwin32_open()
> does, instead of ERROR_ACCESS_DENIED.
This looks sane in a quick once-over, though I haven't tested it.
One tiny stylistic s
Alvaro Herrera writes:
> Is this really all that hard? I'm thinking it could be implemented by
> using the real C sprintf underneath, passing one % specifier and its
> corresponding parameter at a time, coerced to whatever the conversion
> specifier specifies.
The only disadvantage I can see of
"Kevin Grittner" writes:
> I think the main benefit of a sprintf type function for PostgreSQL is
> in the formatting (setting length, scale, alignment), not in making
> concatenation more pretty.
Exactly, which is why I'm so distressed that this proposal not only
hasn't got that, but is designed
Alvaro Herrera wrote:
> the format version is a lot better than the || alternative.
Well, if you're trying to tell me what is easier for me to read,
you're probably wrong. I won't presume to try to tell you what you
find easier to read.
I think the main benefit of a sprintf type function fo
Emmanuel Cecchet writes:
> The new syntax could look like:
> COPY /tablename/ [ ( /column/ [, ...] ) ]
> FROM { '/filename/' | STDIN }
> [ [, BINARY ]
> [, OIDS ]
> [, DELIMITER [ AS ] '/delimiter/' ]
> [, NULL [ AS ] '/null string/' ]
> [, CSV [ HEADER ]
>
Itagaki Takahiro writes:
> LOG messages have higher priority than ERROR and WARNING
> in log_min_messages (PANIC > FATAL > LOG > ERROR > WARNING) now.
> Can I reorder them to ERROR > WARNING > LOG ?
No. That was an intentional decision. LOG is for stuff that we
really want to get logged, in mos
On 9/10/2009 11:06 AM, Tom Lane wrote:
Christopher Browne writes:
With the ALTER TABLE DISABLE TRIGGER functionality added in 8.3, we
already have the ability to do this with foreign key constraints.
That "feature" is a crock that should not be extended, because it
leaves it entirely on the u
The current docs for autovacuum_max_workers suggest it should be modifiable
with a reload, unless I'm reading in awfully silly ways this morning (which
isn't entirely out of the question). Anyway, in the 8.3.7 and 8.5devel
instances I've tried, autovacuum_max_workers can only be set at server start
Kevin Grittner escribió:
> Pavel Stehule wrote:
>
> > what is more readable?
> >
> > select 'i=' || i || ', b=' || b || ', c=' || c ..
> >
> > or
> >
> > select format('i=%, b=%, c=%', i, b, c ..)
>
> Seriously, those are about dead even for me. The concatenation
> might have a slight edge
Hi Robert,
I like this idea, perhaps not surprisingly (for those not following at
home: that was my patch). Unfortunately, it looks to me like there is
no way to do this without overhauling the syntax. If the existing
syntax required a comma between options (i.e. "copy blah to stdout
binary, o
On Thu, 2009-09-10 at 19:52 +0200, Pavel Stehule wrote:
> 2009/9/10 Tom Lane :
> > Alvaro Herrera writes:
> >> alvherre=# select text_format('% was % at % and said % % times',
> >> 'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
> >> text_
* Alvaro Herrera [090910 23:32]:
> Is this really all that hard? I'm thinking it could be implemented by
> using the real C sprintf underneath, passing one % specifier and its
> corresponding parameter at a time, coerced to whatever the conversion
> specifier specifies.
It's not "hard", but pl
LOG messages have higher priority than ERROR and WARNING
in log_min_messages (PANIC > FATAL > LOG > ERROR > WARNING) now.
Can I reorder them to ERROR > WARNING > LOG ? It makes a difference
to "per-destination minimum message levels" feature that I working on.
LOG messages are often used for perf
(moving to pgsql-hackers)
Tom Lane wrote:
> Heikki Linnakangas writes:
>> A completely different approach would be to treat any failure on all
>> platforms as non-fatal. We shouldn't really cut the checkpoint short if
>> recycling a WAL file fails, whatever the reason. That seems like a more
>> r
Hi,
Andrew Dunstan writes:
> I do like the idea of COPY returning a SETOF text[], but I am not at all
> clear on the mechanics of feeding STDIN to an SRF. ISTM that something like
> a RETURNING clause on COPY and the ability to use it in FROM clause or
> something similar might work better.
I e
82 matches
Mail list logo
