Polished version of the patch.
* The feature is disabled by default, enabled by backslash command
\ans. Additionaly, \ansclean cleans the result history.
* Escaping is applied when building COPY IN string
This is patch is a diff between master:230e92c and
https://github.com/maciekgajewski/psql-an
Hi all
I know this topic was discussed before, but there doesn't seem to be
any conclusion.
The lack of unsigned integer types is one of the biggest sources of
grief in my daily work with pgsql.
Before I go and start hacking, I'd like to discuss few points:
1. Is there a strong objection agains
ith statically
typed languages shouldn't have problems dealing with all the issues
surrounding signed/unsigned integers (like the ones described here:
http://c-faq.com/expr/preservingrules.html). Others don't need to use
them.
Maciek
On 27 May 2013 16:16, Tom Lane wrote:
> Maciej
I will implement it as an extension then.
My feeling is that PostgreSQL extensions tend to fall into obscurity.
As an ordinary user it took me really long time to find out that
interesting features are available in form of extensions; they are
certainly under-marketed. But this is a topic for sepa
It would be great. I'm working at the moment on porting integer operations
to unsigned types, and the code is essentially a small number of functions,
repeated for every combination of integer types.
In C++ it could be simply one single set of template functions. Less code;
less bugs.
Maybe this policy should be mentioned on the Wiki, so newbies like myself
(who wouldn't even dare reviewing patches submitted be seasoned hackers)
are not surprised by seeing own name on a shame wall?
M
Thank you for the review!
There were a few english/grammatical mistakes that I went ahead and fixed.
>
Thank you for that. If you could send me a patch-to-a-patch so I can
correct all the mistakes in the next release?
> Additionally, I think some of the string manipulation might be placed
> o
Thanks for checking the patch!
So what's left to fix?
* Moving the escaping-related functions to separate module,
* applying your corrections.
Did I missed anything?
I'll submit corrected patch after the weekend.
M
I'm not really bought into some of the ideas.
but maybe some interactive mode should be usefull - so after
>> execution, and showing result, will be prompt if result should be
>> saved or not.
>
> I like the idea, in addition to the ordinary mode. Personally, I would use
> the ordinary mode, but
> When I tested this feature, I had 30 caches per 5 minutes, and only a
> few from these queries had a sense. Switch between off and on is not
> user friendly. I believe so there can be other solution than mine, but
> a possibility to friendly clean unwanted caches is necessary.
If you know that
The query history is stored within the client, so once the user stops
the client, it is gone. But yes, it would be useful to have some tool
that would allow you to see what's in there.
I could be a command (\showans ?) that would list all :ansXXX
variables, together with the query text and the si
Attached patch contains feature I've implemented for myself, to make
working with huge datasets easier.
I work with large datasets (1E8 - 1E9 records), and the nature of my
work is such that I must dig something out of the data on ad-hoc
basis. I spend a lot of time with psql.
Sometimes a query r
Hi everyone
I used to work on a project storing large quantities of schema-less data,
initially using MongoDB, then Postgres with JSON, and eventually I
implemented BSON support for Postgres to get the best of both worlds:
https://github.com/maciekgajewski/postgresbson
I don't think that JSONB is
13 matches
Mail list logo
