I can see the potential value of per-destination minimum message
levels,
so maybe you should just propose that. But this is a bad place for a
hook.
Features I tried to implement are following:
* per-destination minimum message levels
* per-destination log line prefix
(syslog has t
2009/9/11 Alvaro Herrera :
> Aidan Van Dyk escribió:
>
>> Just to make the task that much harder, if PostgreSQL is going to have a
>> sprintf (in core, or contrib), I *really* hope it's a real sprintf,
>> supporting everything, like:
>> $m positional notation
>> * width argument
>> All the
Aidan Van Dyk escribió:
> Just to make the task that much harder, if PostgreSQL is going to have a
> sprintf (in core, or contrib), I *really* hope it's a real sprintf,
> supporting everything, like:
>$m positional notation
>* width argument
>All the flags [#0- +'] (I as a bonus)
>
On Thu, Sep 10, 2009 at 6:34 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Yes, and GUCs allow users to retrofit this approach onto existing
>> infrastructure without changing their COPY commands. So there's
>> advantages and disadvantages. My question was really for the -hackers
>> at large: is
Andrew,
* Andrew Dunstan (and...@dunslane.net) wrote:
> I don't mind discussing the idea a bit.
Great! Thanks for this. I'll put it up on a wiki and start looking at
implementation details and what the semantics should be.
Thanks again,
Stephen
signature.asc
Descript
On Thu, Sep 10, 2009 at 5:08 PM, Hannu Krosing wrote:
> On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
>> On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
>> > On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
>> >> Hannu Krosing writes:
>> >> > On Thu, 2009-09-10 at 15:06 -0400, Ro
On Sep 10, 2009, at 2:08 PM, Hannu Krosing wrote:
Perhaps you should try changing ANY to a non-reserved word in the
parser and see what happens. If you come up with a way to resolve
the
shift/reduce and/or reduce/reduce conflicts that will probably
result,
submit a patch.
I don't want it
Tom Lane wrote:
> I think the proposal to put a hook here is an end-run to try to avoid
> getting a detailed feature proposal past the criticism of pgsql-hackers,
> and I don't like that either.
I see. If there are bugs in logging module, no one can know research the cause.
> I can see the pot
Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
Consider the suggestion withdrawn.
Let's not throw it out completely. The proposal to have COPY return a
text[] in some fashion is interesting enough that others (ah, such as
myself..) might be willing to put effort
Greg,
> Time to start lobbying for the name change again I suppose. As Bruce said
> two years ago in August 2007:
Man, you are a masochist, aren't you?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> 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' de
* Andrew Dunstan (and...@dunslane.net) wrote:
> Consider the suggestion withdrawn.
Let's not throw it out completely. The proposal to have COPY return a
text[] in some fashion is interesting enough that others (ah, such as
myself..) might be willing to put effort into it. Andrew, could you put
y
Hackers,
Let me try to give more context on some of the things discussed.
Feedback is appreciated.
Thanks
- A
Emmanuel Cecchet wrote:
Josh,
BTW, some of the questions were for -hackers in general to give
feedback. Don't take just my responses as final "what you have to do";
other contribu
Tom Lane wrote:
It might be time to switch COPY over to a more easily extensible
option syntax, such as we just adopted for EXPLAIN.
Could you point me to the thread detailing the extensible option syntax
for EXPLAIN? Is that new to 8.5?
Thanks
Emmanuel
--
Emmanuel Cecchet
Aster Data Syste
Josh Berkus wrote:
I am not really sure why you need a natural key.
a) because we shouldn't be building any features which teach people bad
db design, and
b) because I will presumably want to purge records from this table
periodically and doing so without a key is likely to result in purg
> I am not really sure why you need a natural key.
a) because we shouldn't be building any features which teach people bad
db design, and
b) because I will presumably want to purge records from this table
periodically and doing so without a key is likely to result in purging
the wrong records.
Josh,
BTW, some of the questions were for -hackers in general to give
feedback. Don't take just my responses as final "what you have to do";
other contributors will have opinions, some of which will be more
informed than mine.
Understood.
A) Why would someone want to turn error_logging on,
Tom,
> It might be time to switch COPY over to a more easily extensible
> option syntax, such as we just adopted for EXPLAIN.
+1. And we could maybe have a *single* GUC which was "copy_options" as
a session default.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-h
On Thu, Sep 10, 2009 at 06:34:36PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > Yes, and GUCs allow users to retrofit this approach onto existing
> > infrastructure without changing their COPY commands. So there's
> > advantages and disadvantages. My question was really for the -hackers
> >
On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> The major downside of such a system is that every place where we now
> >> count on being able to store a type in a fixed-size field would need
> >> to be touched.
Josh Berkus writes:
> Yes, and GUCs allow users to retrofit this approach onto existing
> infrastructure without changing their COPY commands. So there's
> advantages and disadvantages. My question was really for the -hackers
> at large: is this the design we want? Or, more directly, is the GUC
Emmanuel,
BTW, some of the questions were for -hackers in general to give
feedback. Don't take just my responses as final "what you have to do";
other contributors will have opinions, some of which will be more
informed than mine.
>> A) Why would someone want to turn error_logging on, but leave
Josh,
See the answers inlined.
Thank you for tackling this very long-time TODO.
Error logging is described here:
http://wiki.postgresql.org/wiki/Error_logging_in_COPY
Questions & Comments:
A) Why would someone want to turn error_logging on, but leave
error_logging_skip_tuples off? T
2009/9/10 Hannu Krosing :
> On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
>> On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
>> > On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
>> >> Hannu Krosing writes:
>> >> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
>> >> >> It
2009/9/10 Robert Haas :
> On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule
> wrote:
>> 2009/9/10 Dimitri Fontaine :
>>> Hannu Krosing writes:
> > 5. Various syntactic sugar to substitute for anyelement. (Not in favor
> > of this myself, it seems to just complicate matters.)
>
> I
On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
> > On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> >> Hannu Krosing writes:
> >> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> >> >> It might be possible to make it work
Emmanuel, Hackers,
Thank you for tackling this very long-time TODO.
> Error logging is described here:
> http://wiki.postgresql.org/wiki/Error_logging_in_COPY
Questions & Comments:
A) Why would someone want to turn error_logging on, but leave
error_logging_skip_tuples off? The pg_log already l
On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule wrote:
> 2009/9/10 Dimitri Fontaine :
>> Hannu Krosing writes:
> 5. Various syntactic sugar to substitute for anyelement. (Not in favor
> of this myself, it seems to just complicate matters.)
I agree; I don't think this solves an
On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
> On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
>> Hannu Krosing writes:
>> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
>> >> It might be possible to make it work, but it's likely to create a lot
>> >> of bloat in pg_type, and
2009/9/10 Dimitri Fontaine :
> Hannu Krosing writes:
>>> > 5. Various syntactic sugar to substitute for anyelement. (Not in favor
>>> > of this myself, it seems to just complicate matters.)
>>>
>>> I agree; I don't think this solves any real problem.
>>
>> agreed, it does not solve the underlying
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> >> It might be possible to make it work, but it's likely to create a lot
> >> of bloat in pg_type, and will make it very difficult to implement
> >> features such
* Pavel Stehule [090910 16:16]:
> first is coming from C and has C semantic - there is only one possible
> tag (without binary compatible types) - you cannot use %s for numbers,
> and %d for strings is some specific value.
>
> sprintf("%d", "10") - show address of static string "10"
>
> second
On Thu, 2009-09-10 at 22:15 +0200, Pavel Stehule wrote:
> 2009/9/10 Hannu Krosing :
> > On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
> >> 2009/9/10 Tom Lane :
> >> > Pavel Stehule writes:
> >> >> I don't afraid about crashing. Simply I have not idea what sql
> >> >> sprintf's behave in
Hannu Krosing writes:
>> > 5. Various syntactic sugar to substitute for anyelement. (Not in favor
>> > of this myself, it seems to just complicate matters.)
>>
>> I agree; I don't think this solves any real problem.
>
> agreed, it does not solve the underlying problem, just may make it
> easier
There is actualised version, for people who are interested on it.
Minimally it should be sample of variadic "any" function for playing.
Don't afraid, I don't plan to send it to commit fest.
regards
Pavel
2009/9/10 Alvaro Herrera :
> Pavel Stehule escribió:
>
>> Please, try to compile and run spri
2009/9/10 Hannu Krosing :
> On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
>> 2009/9/10 Tom Lane :
>> > Pavel Stehule writes:
>> >> I don't afraid about crashing. Simply I have not idea what sql
>> >> sprintf's behave in case:
>> >
>> >> SELECT sprintf('some %s', 10)
>> >
>> > That one I
2009/9/10 Hannu Krosing :
> On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
>> 2009/9/10 Tom Lane :
>> > Pavel Stehule writes:
>> >> 2009/9/10 Tom Lane :
>> >>> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
>> >>> (AFAICS this is simple and painless; about the o
On Sep 10, 2009, at 12:10 PM, Tom Lane wrote:
SELECT sprintf('some %d', 10::mycustomtype)
For the formats that presume an integer or float input in C, perhaps
we could coerce to numeric (failing if that fails) and then print
appropriately. Or maybe int or float8 would be more appropriate
conv
On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
> 2009/9/10 Tom Lane :
> > Pavel Stehule writes:
> >> I don't afraid about crashing. Simply I have not idea what sql
> >> sprintf's behave in case:
> >
> >> SELECT sprintf('some %s', 10)
> >
> > That one I don't think is hard --- coerce the i
On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
> 2009/9/10 Tom Lane :
> > Pavel Stehule writes:
> >> 2009/9/10 Tom Lane :
> >>> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
> >>> (AFAICS this is simple and painless; about the only question is whether
> >>> we
Hannu Krosing writes:
> On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
>> It might be possible to make it work, but it's likely to create a lot
>> of bloat in pg_type, and will make it very difficult to implement
>> features such as anonymous functions (i.e. LAMBDA).
> For functions, anon
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>> I don't afraid about crashing. Simply I have not idea what sql
>> sprintf's behave in case:
>
>> SELECT sprintf('some %s', 10)
>
> That one I don't think is hard --- coerce the input type to text and
> print the string.
>
>> SELECT sprintf('some %d',
Andrew Dunstan writes:
> Tom Lane wrote:
>> I think there were some in the previous discussion --- it came down
>> to using a SRF with arguments that specify the copy source and options.
> Oh, so I guess not stdin.
Well, it'd be nice if stdin were allowed, but we'd have to look into how
to preve
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>> 2009/9/10 Tom Lane :
>>> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
>>> (AFAICS this is simple and painless; about the only question is whether
>>> we want to keep using the name "any", which because of conflicting with
On Thu, Sep 10, 2009 at 3:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane wrote:
>>> 2. Come up with some way to do the equivalent of "variadic any[]",
>>> ie, a variable number of not-all-the-same-type arguments. (This isn't
>>> just a type-system prob
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
An easy fix for that is to allow this form of COPY to return text[]
instead of a fixed number of text columns.
I'd like to see some concrete syntax suggestions for such an animal.
I think there were some in th
Pavel Stehule writes:
> 2009/9/10 Tom Lane :
>> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
>> (AFAICS this is simple and painless; about the only question is whether
>> we want to keep using the name "any", which because of conflicting with
>> a reserved word would a
good analyse, thank you
2009/9/10 Tom Lane :
> Robert Haas writes:
>> The major downside of such a system is that every place where we now
>> count on being able to store a type in a fixed-size field would need
>> to be touched. I don't believe that the overall slowdown in parsing
>> time would
Robert Haas writes:
> On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane wrote:
>> 2. Come up with some way to do the equivalent of "variadic any[]",
>> ie, a variable number of not-all-the-same-type arguments. (This isn't
>> just a type-system problem, there's also the question of how the type
>> inform
Pavel Stehule writes:
> I don't afraid about crashing. Simply I have not idea what sql
> sprintf's behave in case:
> SELECT sprintf('some %s', 10)
That one I don't think is hard --- coerce the input type to text and
print the string.
> SELECT sprintf('some %d', 10::mycustomtype)
For the format
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>> 2009/9/10 Tom Lane :
>>> I think the point of it is that people are used to how sprintf works.
>>> So it should work as nearly like sprintf as possible.
>
>> How sprintf will be print bytea type, or char(n) type values?
>
> Well, that's why it requir
On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> The major downside of such a system is that every place where we now
>> count on being able to store a type in a fixed-size field would need
>> to be touched. I don't believe that the overall slowdown in parsing
>> time wo
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>> 2009/9/10 Tom Lane :
>>> I think the point of it is that people are used to how sprintf works.
>>> So it should work as nearly like sprintf as possible.
>
>> How sprintf will be print bytea type, or char(n) type values?
>
> Well, that's why it requir
Pavel Stehule writes:
> 2009/9/10 Tom Lane :
>> I think the point of it is that people are used to how sprintf works.
>> So it should work as nearly like sprintf as possible.
> How sprintf will be print bytea type, or char(n) type values?
Well, that's why it requires some actual thought and agre
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, particularly since I have the option, if
it get
Hannu Krosing writes:
>> Robert Haas writes:
>>> I am also wondering what happens when someone embeds multiple COPY
>>> statements in a single query
> As long as they COPY from different input files it should be perfectly
> OK. Though this already goes out into SQL/MED land.
Multiple copy from
Andrew Dunstan writes:
> Tom Lane wrote:
>> An easy fix for that is to allow this form of COPY to return text[]
>> instead of a fixed number of text columns.
> I'd like to see some concrete syntax suggestions for such an animal.
I think there were some in the previous discussion --- it came down
Robert Haas writes:
> The major downside of such a system is that every place where we now
> count on being able to store a type in a fixed-size field would need
> to be touched. I don't believe that the overall slowdown in parsing
> time would be significant, but I do think it would be a massive
On Thu, Sep 10, 2009 at 08:23:00AM -0700, David E. Wheeler wrote:
> On Sep 9, 2009, at 6:13 PM, Robert Haas wrote:
>
>> Hopefully this plan is acceptable to everyone. If not, please feel
>> free to reply here.
>
> +1
>
> And I'm available to review again, of course.
>
> Best,
>
> David
>
> --
> S
2009/9/10 Robert Haas :
> On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule wrote:
>>> Really, I think we need a type system that doesn't try to represent
>>> every type as a 32-bit integer. Right now, for example, there's no
>>> reasonable way to write a function that takes another function as an
>>
Tom Lane wrote:
As already said by Andrew on IRC, though, this goes nowhere to help him
address his direct concern, COPY would still choke on input lines that
are containing too few or too many columns...
An easy fix for that is to allow this form of COPY to return text[]
instead of a fi
2009/9/10 Tom Lane :
> Pavel Stehule writes:
>>> On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
I thought the idea was to
provide the same power as sprintf, eg field width controls, numeric
formatting options, etc.
>
>> no - we have to_char function, why we need different formatting
On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule wrote:
>> Really, I think we need a type system that doesn't try to represent
>> every type as a 32-bit integer. Right now, for example, there's no
>> reasonable way to write a function that takes another function as an
>> argument. What we need is a
On Thu, 2009-09-10 at 10:09 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I am fuzzy on the implementation details for making COPY act as a data
> > source for INSERT/SELECT though. I had thought to make EXPLAIN a data
> > source, but it turned out not to be possible (as far as I could tell)
>
On Sep 10, 2009, at 11:16 AM, Tom Lane wrote:
no - we have to_char function, why we need different formatting
system?
Why do we need this at all, when we have the concatenation operator?
I think the point of it is that people are used to how sprintf works.
So it should work as nearly like spr
Pavel Stehule writes:
>> On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
>>> I thought the idea was to
>>> provide the same power as sprintf, eg field width controls, numeric
>>> formatting options, etc.
> no - we have to_char function, why we need different formatting system?
Why do we need this
2009/9/10 David E. Wheeler :
> On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
>
>> Is that what's being proposed?
>
> I think that's what currently works, given the limitations of arrays
> (variadic arguments) to a single data type.
>
>> That pretty much sucks --- it's just
>> another way of concate
2009/9/10 Tom Lane :
> "David E. Wheeler" writes:
>> On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
>>> Is that what's being proposed?
>
>> I think that's what currently works, given the limitations of arrays
>> (variadic arguments) to a single data type.
no, in my code is nothing transformed to s
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_format
>>
"David E. Wheeler" writes:
> On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
>> Is that what's being proposed?
> I think that's what currently works, given the limitations of arrays
> (variadic arguments) to a single data type.
Well, at the very least the parameter markers should be spelled "%s"
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
Is that what's being proposed?
I think that's what currently works, given the limitations of arrays
(variadic arguments) to a single data type.
That pretty much sucks --- it's just
another way of concatenating some strings. I thought the idea
Alvaro Herrera writes:
> alvherre=# select text_format('% was % at % and said % % times',
> 'Pavel'::text, 'here'::unknown, now(), row('a','b','c'), '{42}'::int[]);
> text_format
> --
Pavel Stehule escribió:
> Please, try to compile and run sprintf function from attachment
There's a minor bug in the comparison to PG_NARGS() inside the loop,
fixed in this version.
The one problem I have with this is that if the format string does not
contain any % (and thus there is no extra a
On Thursday 10 September 2009 18:23:13 Andres Freund wrote:
> Hi,
>
> On Thursday 10 September 2009 03:13:40 Robert Haas wrote:
> > Please send me an email (without copying the list) if you are
> > available to review; feel free to include any information that might
> > be helpful in assigning you
Hi,
On Thursday 10 September 2009 03:13:40 Robert Haas wrote:
> Please send me an email (without copying the list) if you are
> available to review; feel free to include any information that might
> be helpful in assigning you an appropriate patch.
I am in.
I dont know yet how much time I will ha
Hi David,
My C isn't all that great, to put it mildly, but I noticed C++-style
//comments like this, which we don't use.
Ok, I will fix that.
Are these dependent on each other, or could they be reviewed, etc.
separately?
The code implementing the functionality are independent (separate
Jaime Casanova writes:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas wrote:
>> Could we
>> have a version of PQconnectdb() with an API more suited for setting the
>> params programmatically? The PQsetdbLogin() approach doesn't scale as
>> parameters are added/removed in future versions,
On Thu, Sep 10, 2009 at 10:33:48AM -0400, Emmanuel Cecchet wrote:
> Hi all,
>
> Finally the error logging and autopartitioning patches for COPY that
> I presented at PGCon are here!
Yay!
> Error logging is described here:
> http://wiki.postgresql.org/wiki/Error_logging_in_COPY
> Autopartitioni
On Sep 9, 2009, at 6:13 PM, Robert Haas wrote:
Hopefully this plan is acceptable to everyone. If not, please feel
free to reply here.
+1
And I'm available to review again, of course.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
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 user's shoulders whether the constraint
Itagaki Takahiro writes:
> For the purpose, I'll submit to add "logging hook" in core, rather than
> fixed features like log_min_messages-per-destination.
The more functionality you put inside elog.c, the higher the probability
that it will fail when the going gets tough (out of memory, for insta
Hi all,
Finally the error logging and autopartitioning patches for COPY that I
presented at PGCon are here!
Error logging is described here:
http://wiki.postgresql.org/wiki/Error_logging_in_COPY
Autopartitioning is described here:
http://wiki.postgresql.org/wiki/Auto-partitioning_in_COPY
The
On Thu, Sep 10, 2009 at 12:47 AM, Josh Williams wrote:
> On Wed, 2009-09-09 at 11:30 -0500, decibel wrote:
>> On Sep 9, 2009, at 8:05 AM, Peter Eisentraut wrote:
>> > How is this better than just reading the information directly from
>> > pg_depend?
>>
>> pg_depend is very difficult to use. You ha
Robert Haas writes:
> Hmm... in fact, what if we just implemented COPY returning text[] for
> a first cut, and forget making it act like a table source for now.
> Then you could COPY to a temp table (with a text[] column) and select
> from there. There's really two separate features here: COPY pr
Robert Haas writes:
> I am fuzzy on the implementation details for making COPY act as a data
> source for INSERT/SELECT though. I had thought to make EXPLAIN a data
> source, but it turned out not to be possible (as far as I could tell)
> without making EXPLAIN a fully-reserved word, which you ve
Robert Haas wrote:
> There are languages much less obscure than Haskell that support
> passing functions as arguments to other functions, such as C.
Or Java, which lets you, for example, pass a Class or Method as an
argument, and includes support for generics.
I see that pgfoundry has pl/Jav
> > pgbench has #defines for number of branches, tellers, and accounts. There
> > are used to populate the tables with -i, but when running actual benchmark
> > it has values separately hard-coded in the query metacommands. This patch
> > makes the metacommands obtain their values from the releva
On Thu, Sep 10, 2009 at 9:56 AM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Last time we opened this can of worms here's what it lead us to:
>> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00222.php
>
> Right, that's the discussion I was remembering.
>
>> As already said by Andrew
Dimitri Fontaine writes:
> Last time we opened this can of worms here's what it lead us to:
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00222.php
Right, that's the discussion I was remembering.
> As already said by Andrew on IRC, though, this goes nowhere to help him
> address hi
On Wed, Sep 9, 2009 at 11:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 9, 2009 at 11:01 PM, Tom Lane wrote:
>>> The thought that comes to mind for me is something "in front of" copy,
>>> that is, give it the text of each line and let it do a text-to-text
>>> transformation before C
Andrew Dunstan escribió:
> As for the feature not being large enough, we have a regrettable
> (IMNSHO) tendency in this project to take simple proposals and
> embelish them with many bells and whistles. Personally, I'm much
> more of a fan of incremental development.
+1
--
Alvaro Herrera
Thanks,
you were right on.
regards,
Maarten
On Wed, 2009-09-09 at 13:47 -0400, Tom Lane wrote:
> Maarten =?ISO-8859-1?Q?Foqu=E9?= writes:
> > The program crashes on PQclear(resu) with the following:
> > *** glibc detected *** ./incident_relay: corrupted double-linked list:
> > 0x09c459c8 ***
>
Tom Lane wrote:
Andrew Dunstan writes:
you mean some sort of filter mechanism?
COPY FILTER function_name ( args) ... ?
That might work. Then we could provide a couple builtin and people could
write others in C or PL/dujour.
Yeah, that's pretty much what I
Peter Eisentraut wrote:
On Wed, 2009-09-09 at 19:18 -0400, Robert Haas wrote:
I agree that ignoring extra columns is a bad idea, but I don't even
like the idea of ignoring missing columns. It doesn't seem like a
good idea to take a spreadsheet and feed it into COPY without doing
any valida
pete...@gmx.net (Peter Eisentraut) writes:
> On Tue, 2009-09-08 at 16:07 -0400, Alvaro Herrera wrote:
>> Tom Lane wrote:
>> > Michael Gould writes:
>> > > It would be nice if we could enable and disable column and table
>> > > constraints. I believe that you can do this in Oracle but this is very
2009/9/10 Hannu Krosing :
> On Thu, 2009-09-10 at 08:44 +0300, Hannu Krosing wrote:
>
>> maybe just let users say what they mean, so first time we have "any" and
>> if we need more then we say "same_as(...)"
>
> Acutually we could be even more SQL-y and have a more verbose syntax for
> pseudotypes
On Wed, 2009-09-09 at 16:31 -0400, Tom Lane wrote:
> The immediate practical problem is
> that we don't store a typmod for function argument/result types.
> I guess we could look into doing that ...
I think that functionality could also end up being useful for other
types.
--
Sent via pgsql-hac
Tom Lane writes:
> Andrew Dunstan writes:
>> you mean some sort of filter mechanism?
>
>> COPY FILTER function_name ( args) ... ?
>
>> That might work. Then we could provide a couple builtin and people could
>> write others in C or PL/dujour.
>
> Yeah, that's pretty much what I was thinking
Hi,
> the two most
> useful are to read in only some of the defined columns, and to output
> to
> a separate disk file any rows which failed to match the expected
> format.
> The latter would not cause the copy to fail unless the count of such
> rows exceeded a user-specified threshold.
>
+1
All
On Wed, 2009-09-09 at 19:18 -0400, Robert Haas wrote:
> I agree that ignoring extra columns is a bad idea, but I don't even
> like the idea of ignoring missing columns. It doesn't seem like a
> good idea to take a spreadsheet and feed it into COPY without doing
> any validation anyway, and this is
1 - 100 of 102 matches
Mail list logo
