A word used only by Postgres developers
https://github.com/postgres/postgres/blob/master/src/backend... :
> Therefore, they offer both exclusive and shared lock modes (to support read/write and read-only access to a shared object). There are few other frammishes. User-level locking should be done with the full lock manager --- which depends on LWLocks to protect its shared state.
It sort of makes sense in context, as a "feature" or a "flourish". It also appears on the pg_hackers mailing list:
> There has been some talk of separating the power to create new users from the power of being superuser (although presumably only a superuser should be allowed to create new superusers). If the planned pg_role rewrite gets submitted before the 8.1 feature freeze, I might look at adding that frammish into it.
and here, from 19 years ago:
> And we get ragged on regularly for the non-SQL-standard features we've inherited from Berkeley Postgres (eg, the implicit-FROM frammish that was under discussion yesterday).
No amount of googling turns up a formal definition or usage outside of the Postgres community. "frammish.org" doesn't seem to be related.
Are Postgres developers starting to evolve their own dialect? Should we call an anthropologist?
159 comments
[ 3.0 ms ] story [ 49.6 ms ] threadhttps://www.opsdash.com/blog/postgresql-cluster.html
Note that the "databases" above are logical databases, not database hosts.
1. https://www.postgresql.org/docs/current/sql-cluster.html
A PostgreSQL server can contain multiple databases; they are independent and you can't access data in one database while connected to another (without dblink or something similar)
As far as I know pretty much every database (and the SQL standard) except MySQL has schemas as an explicit database object and calls them that. What MySQL calls "databases" are actually schemas; they're just containers for database objects and you can query across them (and CREATE SCHEMA is an alias for CREATE DATABASE)
EDIT:
There's a fun trick you can do with multiple schemas that illustrate why they are schemas and not just "containers of things"
You have a "data" schema that contains your table definitions; your actual, real data and indices etc. go here. Only privileged users can access this schema directly.
Then you have an "interface" schema, that contains views and functions used by people; they can refer to the data schema, and with some clever view definitions, you can do it such that they can only access the data using the views and functions in your interface schema.
At some point, you could create an "interface_v2" schema that provides better (or more) methods for accessing your data that's backwards incompatible. Old applications can continue using the "interface" schema by setting their schema search path to "interface" (which would be the default), but new applications can "overlay" the schemas by setting their search path to "interface_v2,interface" and opt-in to new functionality. The "structure" of your data is changed simply by opting in to the new schema.
It's pretty rare for people to do this (they understand versioned web APIs better than versioned database APIs), but it's a thing you can do.
Maybe we're already agreed on this, but for clarity my point is that the common notion of a schema is strictly "the shape of the data" and not "a container for the data, the shape of the data, and a bunch of other stuff". I agree that this latter definition is probably shared across many relational databases and not just Postgres.
Yeah, I see what you are saying I just disagree. Most people who know either use, in the context of RDBMSs, know both, and resolve the ambiguity by context. This is fairly normal, it's very common for words to have multiple common definitions.
> Most people who know either use, in the context of RDBMSs, know both, and resolve the ambiguity by context. This is fairly normal, it's very common for words to have multiple common definitions.
The RDBMS domain alone doesn't suffice to resolve the ambiguity because "structure of data" and "container of tables/etc" are both relevant. I would definitely contend that application developers and operators (though perhaps not DBAs) need to talk about "structure of data" a lot more than I need to talk about "container of tables/etc".
No, it's a namespace within a database, not a container for databases; this is not Postgres specific, it is part of the SQL standard and widely used in other implementations.
It's helpful to think of "the database" as the actual physical storage, and the schema is what the db uses to make sense of how to manipulate/query that data. From that perspective, the SQL DDL is scripting language to manipulate those schema objects ("objects" in the OOP sense, "schema objects" has an actual specific meaning in SQL).
Though if we talk about database weirdness, I never liked Oracle DB's insistence that databases and users are the same thing. Glad I haven't used it for well over a decade now :)
https://docs.microsoft.com/en-us/sql/relational-databases/in...
Maybe it's used as a sort of shibboleth and accidentally escaped internal communication into source code?
It does not seem to be spreading very much, though.
https://handwiki.org/wiki/Biography:Tom_Lane_(computer_scien...
And that's when I knew.
Because that's an exact quote from the docs.
> This section provides an overview of TOAST (The Oversized-Attribute Storage Technique).
> PostgreSQL uses a fixed page size (commonly 8 kB), and does not allow tuples to span multiple pages. Therefore, it is not possible to store very large field values directly. To overcome this limitation, large field values are compressed and/or broken up into multiple physical rows. This happens transparently to the user, with only small impact on most of the backend code. The technique is affectionately known as TOAST (or “the best thing since sliced bread”). The TOAST infrastructure is also used to improve handling of large data values in-memory.
https://www.postgresql.org/docs/current/storage-toast.html
> or were they maybe under threat of becoming an "on call" asset?
This is likely, especially if the person they're talking to tends to leech on other people's skills & time.
I've been known to pretend not to know a damn thing about WordPress, for instance. Even though I do.
You got it. A previous role as a database firefighter was something this individual did not want to continue at their new workplace.
Additional responsibility with no additional authority absolutely sucks when you get (a) pigeonholed, (b) saddled with every single request ever about _______ in addition to your other work or (c) some unholy combination of both.
Especially when ______ only has enough “buy in” from decision makers to make the decision that you need to keep ______ alive because the business “needs”it but apparently not enough to properly source and acquire the necessary resources it needs compared to other business initiatives.
Because “why do we need to do that? I thought you knew about ______ “
Go figure. I’m quite done volunteering myself like that.
Or maybe their manager was just a really big fan of Oracle or something. I don’t know.
I understand my view on the DBA may be limited, but are you serious ? Have I been unlucky and only ran into this weird subcategory ?
The problem is that that is basically where all advancement stopped for them. They learned SQL well enough, they might even know how to do transaction rollbacks, but god help you if you have a real systemic problem that takes detailed knowledge of the whole system to unwind and fix without major data loss.
I'm in the process of trying to convince management to hire a real Postgres expert(both inside and outside the database), because we are currently on a bad, checkbook driven path that is moving tons of our managed RDS Postgres databases to self-managed (and poorly architected) clusters on another cloud. I have neither the time nor the inclination to become a deep Postgres expert.
Of course I'm solving real and challenging problems, but the skills that got me here in the first place are dying on the vine.
Also, on top of that, I'm "the cloud/networking/debugging guy" for about 150 engineers. It's annoying. I want to turn off Slack.
That's a good thing: it gives you great leverage to ensure good retention-pay.
-------
During your 1:1s/"connects"/perf-evals, don't frame it as "I hate being the only one here who knows SQL, I'm quitting/gimmie-a-raise", instead frame it as "I'm proud of the great accomplishments that my unique and deep understanding of both database-theory and SQL in-practice have brought to the company; given my significant responsibilities I now have in the team/company I'm sure you'll "recognize" my now quite-significant leading-role...."
(for best effect make the "money-gesture" with your fingers during the last part).
...I wish I had the gall to do that when I was younger.
Being pigeon holed into boring work just because you're "the guy" is crap, no matter how good the salary is. I quit my last job because of this, and would encourage anyone feeling the same to do so.
No amount of retention pay would raise my spirits in that situation.
Not even this. It's worse when you end up with a whole bunch of tedious, yet very basic work dumped on your by people who have no desire to know what they're doing because "the database guy" can just do it instead.
Note that it's not only "databases" where this happens.
90% of the time my answer was simply "Yeah... That's a bad use-case for a regex. You can use this java snippet to accomplish the same thing."
At the start I would actually solve their request with some hairy regex, but it generally did not perform well and when requirements change they'd be unable to edit it and would find me again to change it.
But part of the problem was they did know simple enough regex for what they wanted to accomplish. Having a few simple regex and some application logic around them would have done it. But they'd often think "that sounds messy, squeaky-clean can probably solve this in a single regex." And while I probably could, it would not be good code nor would it be more performant.
I wouldn't even have minded being seen as the "string pattern/parsing guy". But I was specifically regex-guy in their minds.
Also story for another day and another thread, I was also the MongoDB-guy. Similar to the regex stuff though, in 90% of the questions they'd send to me MongoDB was not the correct choice.
Overall it's more nuanced then could ever fit into an HN comment (yes I brought it up with management, and other issues), but there are a number of reasons I quit. I quit a couple months before a company buyout we knew was going to happen and I had equity. I felt like it was probably the right choice then. I recently got some beers with some of my friends who stayed through the buyout and had equal amounts of equity and learned I did make the correct choice.
https://en.wikipedia.org/wiki/XY_problem
"Hey can I borrow your chainsaw?"
"Sure, you need the gas powered one or the electric one?"
"Oh I'm not sure, which one would be best for cutting my hair?"
But difficult, and with consequences.
I once extracted a PPD from a very expensive printer's firmware because the vendor didn't officially support Linux.
This was when I worked for HP
But here's the thing: it wasn't just HP, it was a lot of print drivers. I suspected that there was some printer driver boilerplate out there, possibly even published by MS, that included this bug.
(And, wow, did I swerve sharply into the off-topic lane for story time. Sorry.)
Told him to contact the provider.
In an interview I don’t want to be intimidating and feigning ignorance can give the candidate opportunity to shine. If they go deep, I can keep up and keep pushing, if they veer into bullshitting I can tell and gracefully conclude without offending anyone.
As a manager, not disclosing depth lets me ask stupid questions more frequently and in more contexts (for the benefit of others, for when I forget something or don’t understand something, as a Socratic teaching method, to help set the culture of asking questions, etc)
Playing dumb is also a good way to avoid responsibility if you hate something, too, if a bit passive aggressive.
And there are tasks you took on at old jobs because they needed to get done and nobody else would do it, so you got stuck. You did them. Maybe you even did them well. But they aren't on your resume, because you don't want to do it again. And if you mention them as anecdotes, you are careful where and when you bring them up.
I've used many databases including mongo. They are all tools like any other with pros and cons and having experience with multiple across domains is a boon.
"... teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery"
- Edsger W. Dijkstra
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...
In my work, I would want to be the know it all, so that I can jump between good projects.
In my consultation business I would want to be the master in the topic I work with.
Depends on the context.
Surely everyone here can relate with the classic "computer guy" everyone takes advantage of. It turns out this exact same thing can happen in actual technology companies. All you have to do to become "that guy" is have knowledge about some vital technology that people don't actually want to care about. People will happily send anything related to it directly your way, increasing your workload and responsibilities with zero additional compensation.
It seems databases are to many professionals what computers are to laymen. They depend on this technology but they don't fully understand how it works or how to fix problems. They still want to define the database schema and make other key decisions. If there's any problem, they don't want the responsibility, they want to be able to offload it to some "database guy". Who wants to be that guy?
;)
The article you linked explains that "sliced bread" is the best thing, to which all later (not just bready) inventions are compared.
I would make that joke.
This is a "jargon" term: https://linguistics.stackexchange.com/questions/2812/argot-v...
Anyway, I think there's an even larger set that "spell" is a member of: metaphorical usage to highlight anything unwanted or erroneous; "code smell" is another.
It's wrong, therefore it smells. It's wrong, therefore it's misspelled. It's wrong, therefore it wants to be different (personification metaphor).
Examples:
In the early days, many features were specified by Not Yet Implemented, so NYI became its own term.
Error messages are meant to be awesome, so anything "Less Than Awesome" (LTA) was considered a bug.
Larry Wall didn't like the term "void context", so he invented "sink context" instead (with all the puns related to it, of course).
There were many more, though I have a hard time coming up with a longer list...
...or, at least, that's what my CS prof claimed in the late 90s :)
Fortunately Perl was reasonable. On the other side of the spectrum you have the impenetrable and pretentiously obnoxious Urbit[1]
[1] https://urbit.org/docs/glossary/moon
...actually, now that I say it, "cyberpunk enthusiast" kinda resonates with the whole design of Urbit.
https://urbit.org/docs/hoon/hoon-school/hoon-syntax
You might need therapy after, but whenever I've met someone who can't stop saying things like "grok" and "less than awesome" I've always thought they needed whatever the opposite of therapy is. They're so well adjusted you can't stand being near them.
> Following this lesson, we will introduce Gall, a vane used to build user space apps. Then we have a walkthrough where we construct an egg timer as a Gall app that interacts with Behn.
nods Gall is a vane that uses Behn, which is an Arvo kernel module. Got it. Crystal clear.
> Here we see that wind produces a wet gate that takes in two molds, which for the move type for Behn are notes and gifts. When a vane needs to request something of another vane, it %passes a note. When a vane produces a result that was requested, it %gives a gift to the callee.
in the general case, y⁻¹ t⁻¹ i⁻¹ l⁻¹ i⁻¹ b⁻¹ i⁻¹ t⁻¹ a⁻¹ p⁻¹ m⁻¹ o⁻¹ c⁻¹
https://www.google.com/search?tbm=bks&hl=en&q=%22frammish%22
That said, I don't see anything that purports to give a definitive definition of the word - everybody who uses it seems to assume that everyone else knows it. And at least at first blush, I don't see anything that attempts to explain the origin / etymology of the word either.
It's the kind of thing you'd almost expect to see in the "Jargon File" but it doesn't appear to be there either.
http://catb.org/jargon/html/go01.html
EDIT: Same with the result from The Royal Dictionary Abridged
EDIT: All the results I can find pictures for are actually `rammish or |rammish or similar. I would assume any results w/out scans available are similarly suspect.