Today I will describe 2 new patches which modify psql:
Continue reading Waiting for 8.4 – psql vs. tabs + wrapped output
Tag: postgresql
MySQL’s timestamp in PostgreSQL
MySQL has this nifty/annoying feature/bug of special data type “TIMESTAMP". It is like a DATETIME, but it gets automatically updated whenever you modify the row.
I'll try to add the same feature to PostgreSQL.
“ERROR: operator does not exist: integer = text” how to fix it?
PostgreSQL 8.3 brought us many great new features. Among them were concurrent autovacuum, enums, tsearch in core.
On of the changes though made a lot of people dislike 8.3. It was removal of implicit casts.
Continue reading “ERROR: operator does not exist: integer = text" how to fix it?
Waiting for 8.4 – pg_conf_load_time, time-related generate_series and enum values in \dT+
3 new functionalities from 3 people:
Waiting for 8.4 – RETURN QUERY EXECUTE and cursor_tuple_fraction
Today another two new additions to PostgreSQL – as You can see may commit-fest seems to work pretty good 🙂
Continue reading Waiting for 8.4 – RETURN QUERY EXECUTE and cursor_tuple_fraction
Waiting for 8.4 – \o and \d+ in psql
Today, we have 2 new changes in psql. One of them is not actually new feature, but I decided to write about it anyway, because of its implications.
Waiting for 8.4 – generate_subscripts
Yesterday, Alvaro Herrera committed patch written by Pavel Stehule which adds generate_subscripts(…) function.
Polish TSearch in 8.3 (polski tsearch w postgresie 8.3)
English disclaimer: this post will be in Polish only, as it's use for other nationalities is somehow limited 🙂
Continue reading Polish TSearch in 8.3 (polski tsearch w postgresie 8.3)
Waiting for 8.4 – “EXPLAIN VERBOSE”
Tom Lane committed his patch which modifies output of “EXPLAIN VERBOSE" command.
My take on trees in SQL
Quick note in polish: jeśli znasz moje poprzednie posty nt. drzew, to ten możesz sobie pewnie odpuścić. będzie zawierał jedynie opis implementacji zbliżony do tego co już jest dostępne.
OK, back to English (or at least my version of English).
Finding a good way to store trees in SQL was/is my long-term hobby. I tried ltree, basic adjacency list, Celko's nested sets way, and nothing really was able to make me feel satisfied.
Ltree is great, but PostgreSQL only (not that it's a big problem). Adjacency list is very simple in insert, update and delete operations, but forces me to use recursive queries in case of some not-so-standard queries. Nested sets are quite the contrary – great for selects, but I simply hate writing insert/update/delete to these trees.
Is there anything better? I think so.